STREAMS has become an industry de facto framework for implementing data communication network protocols, as well as various types of device drivers. STREAMS provides a bidirectional data path between a user level process, such as an application program, and a device driver in the kernel. A typical stream includes three main types of processing elements: a stream head, optional processing modules, and the device driver.
The device driver is found at the end, or tail of the stream. Drivers can be added to the kernel simply by linking their object files with the kernel object files. However, in the teachings of the prior art, the stream head is fixed since the stream head is provided with the kernel proper.
The stream head includes a set of routines that provide an interface between the user process level (known as "user space") and the rest of the stream, which executes only at the kernel process level (known as "kernel space"). Each stream head of the prior art is customizable to a only a small extent by selecting from among limited processing options it supports. In the prior art teachings, the stream head processing routines are used with every stream in the system.
Access to a stream is provided via an open system call having a STREAMS file descriptor. For example, when a user process makes the system call, the stream head routines are invoked, resulting in data copying, message generation, or control operations being performed. If a device driver is not already open, the open system call will build the stream. Once the stream is constructed and the open has completed successfully, another open of the same device creates a new file descriptor referring to the same stream.
The stream head is the only component in the stream that can copy data between the user process level and the kernel process level. All other components effect data transfer solely by communicating messages, and thus are isolated from direct interaction with any user process. Accordingly, the modules and drivers of the open stream execute within a context of the kernel process level and therefore lack context or knowledge of the user process level. This lack of context promotes a "one-size-fits-all" approach to process communication between user processes and kernel components. Such an approach limits modules and drivers from adapting stream data interpretation, stream execution behavior, and the like to satisfy changing requirements of whatever user process is currently executing upon the open device driver.
For example, modules and drivers in STREAMS of the prior art are particularly limited in adapting to support a transition from thirty two-bit applications running on a thirty two-bit kernel and processor architecture to sixty four-bit applications running on a sixty four-bit kernel and processor architecture. In order to protect an investment that computer users have in the thirty two-bit user applications as they migrate to the sixty four-bit kernel, STREAMS must be adapted to support both thirty two-bit user applications and sixty four-bit user applications running on the sixty four-bit kernel. Since the modules and drivers of an open stream execute within a context of the sixty four-bit kernel of the example, and therefore lack context or knowledge of the thirty two-bit application, the modules and drivers are limited in adapting stream data interpretation, stream execution behavior, and the like to satisfy requirements of the thirty two-bit application, which are different than requirements of the sixty four-bit application.
In general, whenever data is touched, application and kernel performance are degraded. Therefore, whenever data is touched at the stream head, a good guideline is to perform as many mutually exclusive operations in parallel at the stream head as possible, so as reduce requirements for touching the data again downstream. What is needed is an apparatus and method for kernel level stream processing modules or device drivers identifying message processing functions and for controlling execution of the identified functions at the stream head, so that the functions are available at the stream head to adapt stream data interpretation, stream execution behavior, and the like in accordance various system requirements such as requirements of devices or user processes.